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IN THIS ISSUE Todd Post 


What Is This Fourth Dimension? 


Soon after we started publishing ASK, / heard from some 
of our NASA readers that we needed to feature more stories 
about managing research projects 


The research community at NASA, I was told, is too 
often overshadowed by the folks who build hardware. 
Four of NASAs nine centers, after all, are research centers. 

I hope stories in several of our recent issues have 
satisfied some of those early critics. But to any project 
manager of a research project who may still feel slighted, 
well, here is an issue for you. 

In working on this issue, what IVe learned is that 
managing research projects demands an understanding 
of what Dr. Robert J. (Joe) Shaw calls the fourth 
dimension: politics. His story, “Getting Politically 
Active," explains how he has evolved from being an 
observer of organizational politics to actively politicking 
for his projects. Carol Ginty, who like Joe Shaw is located 
at NASA's John Glenn Research Center, knows that the 
technical report doesn't always sell the research. That's 
why she's always looking for things that will — and finds 
them wherever they turn up. 

Tim Flores returns to ASK this issue. I interviewed 
Tim for Issue 2. At the time, he was on leave from 
NASA's Ames Research Center, working on a Masters 
degree at MIT. Finished now, he has a story, “Earthly 
Considerations on Mars,'' about the research he did for 
his thesis. Tim looked at two Mars projects, the 
successful Pathfinder and the ill-fated Surveyor, 
attempting to understand the difference between a 
successful mission and a failed one in terms of the 
organizational structures of the project teams. Research 
projects often give us many surprises, and this one is no 
exception. 

Our interview this issue is with Dr. Michael Hecht, 
a project manager at the Jet Propulsion Laboratory. 
Among other things, Mike shares what it was like 


working as the project manager and co- investigator on 
an instrument scheduled to fly on an upcoming Mars 
mission. Did his dual role on the project pose a conflict 
of interest? Read the interview and see. 

In the Special Feature, APPL Knowledge Sharing 
Manager Denise Lee has a story about how the APPL 
Transfer Wisdom Workshops have evolved. Denise and 
her APPL teammates conduct one-day workshops at the 
NASA Centers, using stories from ASK to promote a 
knowledge sharing culture at each Center. Along with 
the story by Denise, we've included stories by partici- 
pants from some of the workshops. 

Lastly, we celebrate the life of Frank Hoban, who 
passed away unexpectedly in December. Frank was the 
editor of Issues in Program and Project Management , 
published by NASA and dedicated to research done by 
NASA managers. Issues appeared throughout the late 
1980s and early 90s. “From The Director's Desk,'' Dr. 
Edward Hoffman's column, is a remembrance of Frank, 
and in the “Loop" we pass along some tributes written 
by Frank's friends and colleagues. 

Hope you enjoy this issue of ASK. Remember, this 
and all issues are for you. • 



ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 3 


FROM THE DIRECTOR S DESK Dr. Edward Hoffman 


Remembering Frank Hoban 


Years ago , / interviewed for a job I wasn't sure I wanted 
with a man who wasn't confident he wanted me 


The job was being second-in-charge of NASA's 
P rogram Project Management Initiative (precursor to 
the Academy of Program and Project Leadership), and 
my interviewer was Frank Hoban. 

Shortly after we exchanged typical pleasantries, Frank 
jumped right into discussing ideas, beliefs and goals. After 
twenty minutes he asked, "So, when can 
you start?" I made the second best 
decision of my life and accepted the job 
on the spot. 

I remember a typical Frank 
remark when embarking on a new 
assignment, "Lets get started soon 
because we can do some really 
important things, and let's remember 
to have fun." Few days were as 
enjoyable as meeting with Frank over 
lunch and hearing stories of escorting Wernher von 
Braun to the Dick Cavett show, or working for George 
Low on the Low Cost Systems Office, or the early days of 
Space Station. 

Frank came from a project world. He much 
preferred addressing real issues by working with the best 
people and staying focused on the customer require- 
ments. When I first started with Frank, he informed me 
that the more time 1 spent in my Headquarters office the 
less effective I would be. The customers, experts and 
practitioners, were in the field — spend time with them. 

He made that point personally by the way he used 
his last few weeks before leaving NASA. He escorted me 
on a tour of each of the centers. We met with all of the 
working groups and individuals who were so vital to the 


project management community. I still remember him 
telling everyone what a wonderful leader I would make, 
and his strong insistence that I receive their support. 

Frank had accepted a university teaching position. 
He felt it was time for a new adventure and assured me 
he would always be nearby to help — and he was. Over 
the years we stayed close. One time, 
several years ago, Frank invited my 
family to his New Year's Day party. We 
went for a walk on the grounds of his 
beautiful home, the two of us, and he 
asked me how things were going. This 
was during a period of excessive travel 
and long hours. I knew he could sense 
I was burning out. He shared some of 
his experiences and then talked from 
the heart about the most important 
thing being family. He warned me that it was easy getting 
caught up in the excitement of work and travel. 

The last time I saw Frank was at the Goddard Space 
Flight Center. We had a few minutes to talk. We 
discussed possibilities, exchanged ideas, caught up on 
people and agreed to get together for lunch soon. 
Leaving, I noted how his eyes sparkled with energy, 
excitement and adventure. I knew he was planning the 
next big thing. 

Frank was a big part of what makes NASA special. 
He was part of a hero generation that faced challenges, 
dreamt big and remembered to have fun. He embodied 
a love for family, country and NASA. 1 have always 
considered myself an extremely lucky person for having 
known him. • 


Leaving, I noted how 
his eyes sparkled 
with energy, excitement 
and adventure. 

I knew he was planning 
the next big thing. 
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Considerations 

on 

Like the rest of the country, I read the newspaper accounts 
of NASA's Mars missions in the late '90s. Headlines touted the 
success of the 1996 Mars Pathfinder and, later, highlighted two 
of the 1999 Mars Surveyor program missions as failures. Unlike 
much of the country, my work at NASA gave me more than a 
passing interest in the headlines. 
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Y A southwest view from Pathfinder’s 
landing spot reveals the rocky 
Martian landscape. 


When I left my job at Ames Research Center in 
1 999 to go back to school, both of these projects were 
fresh in my memory. So, when it came time to choose a 
research project for my Master's thesis, the Mars 
missions came to mind. I wanted to work on something 
of real value to NASA and, by looking at these projects 


from a new perspective, I hoped I would have something 
to offer the Agency. 

Much had already been written about the Mars 
missions. At least two books had detailed the success of 
Pathfinder from start to finish. Committees had studied 
closely the Mars Climate Orbiter and Polar Lander, two 
not-so-successful Surveyor projects. Why did I think I 
had something new to say? 

Asking questions 

The Pathfinder, Climate Orbiter and Polar Lander 
projects all came out of the Jet Propulsion Laboratory 


(JPL). They were conducted under the same "faster, 
better, cheaper" mandate, were all of comparable scope 
and shared many similar elements and even some of the 
same team members. But they had very different end 
results; what accounted for the difference? Aside from 
the reported technical issues, what could have been the 
deciding factors between success 
and failure? Could the organiza- 
tional design, politics or culture 
have been a factor? 

With the help of my advisor at 
MIT, I developed my research 
project as an organizational study of 
the Mars projects, and I developed a 
lengthy set of questions to use when 
interviewing team members from 
the three projects. I anticipated that 
some of the people I spoke with 
might, quite understandably, be 
sensitive about discussing their work on a so-called 
"failed" mission, and I gave this a lot of thought. 

When it came time to contact my research subjects 
on the Orbiter and Lander projects, I made it clear that 
I wasn't interested in finger pointing and I wasn't 
looking to blame anyone for failures. I explained that I 
was studying the strategic design of each project, i.e., 
the grouping, linking and alignment of the project. I 
wanted to look at the political environment to see how 
the goals and interests of stakeholders affected the 
outcomes, and I wanted to understand the working 
culture of each project. 


One fundamental 
element distinguished the 
successful mission from 
the failed missions: 
teamwork. 



Because dust extends high into the 
atmosphere, the Martian sky stays 
bright for up to two hours after sunset. 


In the end, I was impressed by the 
generous response of the part ieipants: MBIP ^ 

expressed B^H^fl 

share their knowledge and to help with 1 

Getting answers 

I interviewed, in great depth, eight key 
the suhjeet 

worked on ho;h Pathfinder md Snr\ evor. BBBffl | 

and I intei'viewed him separately about 

eaeh). 1 expeeted to find that the 

Pathfinder differed from the other 

projeets on a number of lev els: resources. BB 

eonstraints. philosophy, and personnel. BH 

And this was. to some extent, true. But 1 BB . 

was extremely surprised to find one 

fun lament, il element distinguished ^^BBH| 

the sneeessfnl mission from the failed 

You can't underestimate the value of " 
effective teamwork. The Pathfinder team developed 
trusting relations within a culture of openness. They felt 
free to make the best decisions they could with the 
resources available to them, and they knew that they 
weren't going to be crucified for mistakes. That trust 
never developed in the other programs. 

Why did the individuals of one team work so well 
with another, while the other teams suffered from 
numerous conflicts and communication gaps? Tied into 
this are a number of factors. One of the things that 


Pathfinder did was to develop a flat 
organization, which allowed team 
members to make decisions across 
the board. They were not forced to 
follow the standard hierarchical 
protocol that usually exists in 
government programs. Team 
members were encouraged to 
speak to one another directly, 
rather than through managers, 
and they felt fewer bureaucratic 
limitations on their work. 

Another factor: collocation. 
The Pathfinder team built their 
own spacecraft, and they were able 
to co- locate almost all the team on 
one floor in one building. Team 
members had frequent, informal 
face-to-face interactions on a daily 
basis. Consequently, they could 
respond to emerging issues quickly. 
Contrast to that the distance between the Orbiter/Lander 
prime contractor, Lockheed Martin Astronautics, in 
Colorado and the mission team at JPL in California. 
Working with dispersed teams made communication 
failures more likely, and communication failures, in 
turn, prohibited developing trust. 

Never underestimate the power of positive 
thinking. Even though the budget for Pathfinder was an 
order of magnitude smaller than previous Mars 
missions, team members turned that into a "can-do" 


* 

t 




motivational factor. Management took the first step in 
creating a trusting environment that set the tone for 
positive results. The atmosphere brought out a strong 
performance ethic and the relentless 
desire to accomplish the mission. In 
contrast, the challenges for the 
Surveyor program were presented 
with a negative connotation of “two 
for the price of one" and “it couldn't 
be done." 

Not surprisingly, my research 
uncovered many of the same factors 
identified by earlier studies as critical 
elements to the relative success or 
failure of the Pathfinder, Orbiter and 
Lander missions. The striking differ- 
ence between the projects, however, became clear during 
my research: the cooperative relationships between team 
members across the boundaries on the Pathfinder 
mission did not exist on the other missions. 

Without a doubt, sound science and technical 
proficiency are crucial to a project. But an examination 
of the Mars missions tells us that we can't afford to 
overlook the relationships between the people doing 
the work. 


If there's one thing my research taught me, it's that every 
project, no matter what its technical specifics, comes 
down to being a human capital effort. • 


Lessons 

• You can enable success but cannot create it. Project 
managers must find the right balance between giving 
people the right independence (trust) to accomplish great 
things and providing the guidance to help them do it. 

• Project management is a people industry. Gaining the 
trust of your followers will grant you more influence 
than any formal authority. 


We can’t afford to 
overlook the relationships 
between the people 
who work on a project. 


In many ways, my research continues. I'm trying to 
apply the lessons I learned to my current work situation. 
I've pushed for more face-to-face communication and 
I'm trying to help build a relationship of trust between 
members of the various teams working on my project. 


Question 

In research , we expect to be surprised because that's how we 
leam. On a project , we often greet surprises with some trepida- 
tion , understandably. How might you rethink "surprises" on a 
project as learning opportunities? 


iMjr 





m, r*** 
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W 1 In 2001. TIM FLORES earned his Masters of 

f J Science and Engineering Management from the 
UigAQi J Massachusetts Institute of Technology (MIT). 
^ 1 Flores attended MIT as part of NASA’s 
Hr * Accelerating Leadership Option (ALO), which 
allows some of NASA’s most promising mid- 
career project managers to develop skills needed to lead the 
Agency in the 21st century. The program combines business 
management and systems engineering studies at MIT with a 
one-year developmental assignment. 

Managers from all nine NASA Centers have participated in the 
three-year-old program. In their developmental assignments, 
graduates have worked at IBM, Raytheon Corporation, 
MC Corporation, National Reconnaissance Office, NASA 
Headquarters offices and other industry and Agency settings. 
Tim Flores’s post-grad assignment with L3 Communications has 
been extended and he continues to work on the Stratospheric 
Observatory for Infrared Astronomy (SOFIA), a joint project 
between NASA and the German space program. 

You can find Tim Flores’s thesis about the Mars projects, 
"Organizational Team Characteristics That Enable Successful 
Projects at NASA: A Framework for the Future,” on the NASA 
APPL Web site at http://appl.nasa.gov/resources/flores.htm 


Understand your stakeholders' 
perspectives, or run the risk 
of seeing your program being 
killed off in an instant. 


the people assigned to UEET worked 
in the HSR program and the 
Advanced Subsonic Technology 
(AST) program, which was cancelled 
at the same time. Though these NASA 
employees and industrial partners 
suffered collateral damage when the 
old programs were terminated, I 
needed to get them to buy in to the 
new program. 

I spent a lot of time explaining my 
vision for the new program — and listening to their 
complaints. That was okay; people need to vent, and 
you've got to understand that. I believe that by commu- 
nicating with all the people associated with this program 
and by developing a relationship with them, we 
developed a high degree of support for the program — to 
the point that some of our contractors have taken the 
initiative to spread the message that the UEET Program 
deserves continued funding. 

I want to make very clear, though, that I have never 
encouraged any industrial partner to go out and lobby 
Congress; that's not an appropriate activity for NASA 
personnel. I think we have a strong, clear vision in 
UEET and we deliver timely, high-quality technical 
products. This vision and our success in realizing the 
vision inspire people to take appropriate action. 

I have also spent a good deal of my time with our 
stakeholders at NASA Headquarters. Over the years, the 
leadership in the Office of Space Technology has 
included people of very different backgrounds, experi- 
ences, and approaches to program planning. Each and 
every one of these individuals has been a good person, 
but they come from different perspectives. My advice to 
anyone heading up a research program at NASA: 
Understand your stakeholders' perspectives, or run the 
risk of seeing your program being killed off in an instant. 

And that is also my advice to all program and 
project managers. You must engage yourself in under- 
standing the environment in which your program or 
project operates. To put it simply: You can run, but you 
cannot hide from politics. Either you will influence the 
politics that surround your program, or politics alone 
could determine the fate of your program. 1 learned the 
hard way that a manager can't afford to be detached. • 


Lessons 

• Projects can, and do, succeed because of politics. And 
they can fail due to politics, as well. Politics does not have 
to be a dirty word, if it means working closely and openly 
with customers and stakeholders; it is an essential 
approach that requires continuous dedication of time 
and attention. 

• Project management is a people industry. Gaining the 
trust of your followers will grant you more influence 
than any formal authority. 

Question 

How do you get buy-in from the stakeholders on your projects? 


“I suppose we all come to project management through 
unconventional paths," says DR. ROBERT J. (JOE) SHAW. 
While working on his PhD at Ohio State University, Shaw 
didn’t expect to become a project manager, or to spend 
his career at NASA. Explains Shaw: “My advisor at Ohio 
State told me that NASA is a great place to go for five 
years, learn, gain experience, then get out and get on to 
the real thing. For me, the real thing was to become a 
university professor. But as that great philosopher of our 
time, Yogi Berra, said, ‘When you come to a fork in the 
road, you take it.”’ After starting out as a Division Manager 
in the Icing Program at Lewis, now the John Glenn 
Research Center, Shaw gravitated to a formal project 
management role leading the High Speed Research 
Project. Most recently, he has managed the Ultra Efficient 
Engine Technology Program Office and started up the 
Vehicle Systems Program. 
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Early in my career, I did a 
lot of work in icing research. 

My research group had 
been trying to get money to 
upgrade our icing research 
tunnel, and it wasn't going 
well. We weren't considered 
mainstream enough, I suppose. 

We were given a certain budget 
every year and we were told to do 
the best we could with that money. 






wrong. The answer was, "You didn't do a damn thing 
wrong." There were forces at work beyond our 
immediate control. 

The program was terminated around Thanksgiving. 
While I was at home for the Christmas holidays that 
year, I put up shelves in our basement. I worked out 
some of my frustration with work on my home project. 

I still have a lot of drill holes in the wall, and there are 
names associated with each one of those holes. 

Shortly after the HSR program was cancelled, Dan 
Goldin, the NASA Administrator at the time, told my 
boss that he wanted to start a new program — somewhat 
similar to the program that had been terminated but 
different enough to be considered revolutionary. My 
boss told me that he wanted me to do this job. 

I wasn't terribly excited about jumping right back 
into the political fray. I told him point blank, "I don't 
w’ant it." He said, "Oh, yes, you do." So, that was the end 
of that discussion. 

Politics, Redux 

The Ultra Efficient Engine Technology Program 
(UEET) is a collection of technologies aimed at 
impacting future gas turbine engine designs. Some of 



Out of nowhere came a front-page news story 
about a horrible plane crash that was due to icing. It 
wasn't the icing that we were studying but, nevertheless, 
icing research had new currency (yes, pun intended). 
Suddenly, the money we were asking for — and more — 
was made available to us. 

I wasn't directly involved in bringing that money to 
the program. I stood by on the sidelines and said, "Well, 
I don't understand how the politics of this works exactly, 
but it seems to be benefiting me and so that's nice." 
Detachment served me fine in that case. Many years 
later, however, I was involved in another political football 
match and, this time, the ball didn't bounce my way. 

On My Own 

In 1999, the program I was working on. High Speed 
Research (HSR), was terminated. I could spend pages 
talking about w'hy it was terminated, but at the risk of 
sounding like sour grapes, let me just say this: Over a few 
weeks (literally, a few), we lost our national agenda and 
priority. We went from the top program to the one that 
you didn't want to talk about anymore. 

It was a very upsetting experience. Many of the 
people who worked for us wanted to know what they did 



FOR IRE PROJECT 

by Carol Ginty 




ADVOCATING RESEARCH IS A LITTLE TRICKIER 
THAN SELLING OTHER PROJECTS AT NASA. 
YOU CAN POINT TO A SATELLITE. YOU CAN 
POINT TO A ROCKET. YOU CAN SEE THE 
SHUTTLE AND THE INTERNATIONAL SPACE 
STATION. BUT IT'S DIFFERENT ON THE 
RESEARCH SIDE. HOW DO YOU DISPLAY 
COMPUTATIONAL FLUID DYNAMICS? HOW 
DO YOU GET SOMEONE TO UNDERSTAND 
THE VALUE OF COMPOSITE MATERIALS OR 
NANO-TUBES THAT THEY CANT EVEN SEE 
WITHOUT A MICROSCOPE? 


Turn up the heat: Material processing facilities 
at the John Glenn Research Center host high- 
temperature research. donald huebler 


Where I work at NASA's John Glenn Research 
Center, we joke about how we all went to engineering 
school, but what we really needed were classes in 
political science and marketing. These days, it seems 
that technical decisions aren't made strictly based on the 
merits of the technology. At their root, decisions about 
research projects are largely political. 

It all comes down to this: How do you convince 
people that low-visibility projects have the potential to 
change the way they live, and that they share a vested 
interest in the outcome of this work? And it's not just 
the American public or Congress that I need to 
convince. I've found that I have to do a lot of "stumping" 
within the Agency about why this technology is so 
important. 

As a project manager, I have to be aware of what's 
going on at my research institution relative to other 
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programs and projects — and I have to be on the lookout 
for any threats that might be coming my project's way. 
When my program manager, Gary Seng, gets mandated 
budget cuts, he has to take the money out somewhere. 
An important part of mv job is convincing him that my 


How do you get someone to 
understand the value of composite 
materials or nano-tubes that they 
can't even see without a microscope? 


project shouldn't be the one that gets cut. 

It helps that I'm genuinely passionate about what 
we're doing. So, whenever 1 have the opportunity to 
present our technology to upper management, I don't 
simply report the status of our milestones. I try to make 
every presentation exciting. I show the potential of what 
we're working on and I talk about benefits down the 
road. I spin the project however and to whomever I 
think it needs to be spun. 

Currently, I'm managing advanced high tempera- 
ture materials research. Almost every system study has 
identified materials as the key to future technological 
developments. So, I'm always out there looking for any 
nugget of information that I can pull 
from one of the studies. I'm looking for 
that sound bite capable of influencing 
someone in about 30 seconds — 
something that will leave him or her 
thinking, "Oh, we really do need this 
materials research." 

The technology being developed in my project will 
enable a commercial subsonic engine to perform at 
higher temperatures. When you raise the temperature in 
an engine, the engine runs more efficiently. You reduce 
emissions and save money because the engine burns less 
fuel. Most current materials have reached their inherent 
thermal capabilities. So, we are developing both new 
material systems and coatings for existing materials to 
achieve this goal. 

If I simply told you that millions of dollars have 
gone into this research and that the operating tempera- 
ture of an engine has been increased by 100 degrees 
Fahrenheit, you might jump to the conclusion that we 
haven't accomplished much, and that we've been 


wasting money. Instead, I point out that a think tank at 
Stanford University recently did a study and concluded 
that raising the engine temperature 50 degrees 
Fahrenheit across the entire fleet of commercial airlines 
would save $1 billion annually in fuel consumption. 

That gets people's attention. 
And that's what I mean by 
selling the project. 

I have learned that the 
technical paper doesn't sell 
a project. Frequently at 
reviews, you watch people 
nod off in the middle of all 
the technical data. While it's 
exciting to the researcher, 
it's often boring to the decision makers. If you want their 
vote, you need to get their attention and you need to 
show them value. • 


Lessons 

• There are times when the role of the project leader is 
simply to sell the project. On a research project it is often 
more crucial and more difficult, and requires focus, 
effort, and creativity. 

Question 

Is there a point at which " selling " a project can become " selling 
out" a project? 


I have learned that the technical 
paper doesn't sell a project. 


CAROL GINTY has held several positions at the John 
Glenn Research Center over the last 20 years, all 
involved with the research and development of 
advanced propulsion materials for aeronautics appli- 
cations. In 1989, she became a subproject manager 
for Analytical Methods in the High Temperature 
Materials (HITEMP) Program where first-life prediction 
methods were formulated for high temperature 
composites. In 1991, she became the Deputy 
Program Manager for HITEMP and assumed the role 
of Manager in 1998. She was responsible for the 
successful completion of the program, which had an 
unprecedented, 1 2-year uninterrupted life cycle. 
In 2000, she formulated a follow-on project, Higher 
Operating Temperature Propulsion Components 
(HOTPC), and is currently managing that effort. 



14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 



SPECIAL FEATURE: KNOWLEDGE SHARING 



THE OPPORTUNITY TO ENGAGE IN A 
KNOWLEDGE SHARING ACTIVITY. 


YOU KNOW THE FEELING: YOU THROW A PARTY, INVITE A LOT 
of people and you pray they show up. When we planned 
one of our first Transfer Wisdom Workshops (TWWs) at 
Goddard Space Flight Center, we expected to run a 
workshop with 25-30 people. Instead, only five people 
from Goddard had entered the room by the time we 
were supposed to start. 

It’s hard to “share" knowledge when you don't have 
people there to do the sharing, but you can only clear 


your throat so many times and say, “Maybe we should 
wait another ten minutes and see if a few more people 
get here." Eventually, we got things underway. 

TWWs focus on practitioners' stories about their 
work experiences. We craft the stories we discuss and the 
questions we ask to bring out concrete examples of best 
practices and lessons learned. Our aim is to help the men 
and women who work on NASA projects step away from 
their work for a moment in order to better understand it, 
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SPECIAL FEATURE: KNOWLEDGE SHARING CONTINUED 



WE SIMPLY HAD TO DO A 
BETTER JOB OF GETTING 
OUR MESSAGE OUT THERE. 

learn from it and then share what they have learned with 
others. By the end of a workshop, we have participants 
familiar enough with the concept of sharing knowledge 
through narratives that they write their own stories. (You 
can see a few of these stories on pages 18-19.) 

Though we had only a handful of participants at 
that first Goddard workshop, we engaged them in lively 
discussions and, by all accounts, they left feeling that 
they had spent their time productively and had learned 
a great deal from one another. We had done a solid job 
running the workshop — but it was apparent that we had 
done a poor job recruiting participants. 

At a coffee shop not far from Goddard, the 
Knowledge Sharing (KS) team gathered for a debriefing. 
I got into a discussion with Dr. Alexander Laufer 
(Editor-in-Chief of ASK and creator of the TWW 
concept) about our planning strategy. Alex's idea had 
been to go to each of the Centers and spend face-to-face 
time recruiting KS affiliates who would, in turn, sell the 
workshop for us. I pointed out that the plan sounded 
great in theoiy, but our affiliates were all busy people, 
top-notch project managers themselves, and they had 
precious little time to tout our initiative and make sure 
chairs were filled at our workshops. 

I suggested that rather than relying on affiliates, I 
should "work" each Center to guarantee we had an 
adequate turnout. Alex argued that I wouldn't know 
how to identify the right people. I countered that if we 
found ourselves on the morning of a workshop not 
knowing how many people were going to walk through 
the door, then we weren't doing a good job marketing 
our program. 


I believed that if I had more influence over signing 
up workshop participants, then I could make the 
process work. In fact, 1 promised that 1 would. I didn't 
have anything to back me up other than my confidence 
in the philosophies we were teaching and my belief in 
the value of the TWWs. We simply had to do a better job 
of getting our message out there. 

To my surprise, Alex came to me the next day and 
told me that he thought my approach to the problem — 
recognizing the need for hands-on marketing — was 
creative and might just work. He had to be willing to 
accept a risk, but project managers have to do that all 
the time. He gave me the go ahead. 

NEXT STOP, FLORIDA 

Our next workshop was at Kennedy Space Center in 
Florida. Two months before the workshop, I went with 
Michelle Collins (then NASA's KS project manager 
and someone who had spent most of her NASA career 
at Kennedy), and we walked the halls of the Center, 
talking with experienced project managers we knew 
from previous KS activities as well as managers who 
had been recommended to us. We met with 30 people 
in 2 days. 

We introduced ourselves, gave an overview of the 
initiative and asked the managers for the names of 
people we should invite to the workshop. Then we 
asked them to encourage people on their projects to 
attend. We only requested 15-minute meetings, because 
we knew that the only way to get on a busy manager's 
calendar was to ask for a brief meeting and to honor 
that timeframe. 

This idea of asking experienced project managers to 
recommend younger project managers for the Workshop 
goes along with our vision of knowledge sharing as a 
grassroots initiative. If young project managers get a form 
letter from NASA Headquarters suggesting they 
consider attending a new program, how likely are they to 
take time away from a heavy workload? If a project 
manager they know and respect tells them that it's a good 
thing to do, they're a lot more likely to go. 

The people we're trying to get to come to the 
workshop aren't necessarily project managers or even 
people on a project management career track. We're 
targeting the team of people who work on a project, 
dying to get them to embrace the philosophy of 
knowledge sharing and put to use some of its practices 
and lessons. The idea is that projects have many 
components — for instance, procurement, systems 
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“What we’re trying to do in this initiative is promote learning," says DENISE LEE, who manages 
Transfer Wisdom Workshops and Masters Forums for the APPL Knowledge Sharing Initiative. 
Lee didn’t just come off the street to start doing this; her Masters degree in Organizational 
Learning focused on Knowledge Management. Says Lee of her current work, “My role is to 
create the space where people can come together to learn from one other." 

In a project like the Transfer of Wisdom Workshops, Lee works to change workplace mindsets and behaviors, 
and to help instill a culture of knowledge sharing at NASA. Her strategy? “Perseverance," says Lee, “is 
necessary in any change project. But even more important is a willingness to learn and adapt as you go” 




engineering and human resources. All the different 
disciplines contribute to a project. 

On the same visit that we spoke with project 
managers, we identified a champion in Training and 
Development at Kennedy, Tim Gormley. The idea was to 
cultivate a local champion because we were only going 
to be on site for two days. We sold Tim on the concept 
and he stayed with us every step of the way. 

RSVPs for the workshop started coming in almost 
immediately. I didn't just let an RSVP drop into my 
email box. I called each person back and said, "I 
received your RSVP. Thank you so much. We are 



THE MATERIAL WE PRESENT 
SPEAKS FOR ITSELF 
ONCE WE GET PARTICIPANTS 
THROUGH THE DOOR. 


looking forward to meeting you and introducing you to 
the Knowledge Sharing Initiative." 

How many workshops do you sign up for where 
someone calls you? Where you talk to the person who's 
actually going to run the workshop and they say, "I'm 
really looking forward to meeting you"? I tried to 
establish a relationship from the moment someone first 
heard from me. And from that moment on, I understood 
that my credibility was on the line. 

SHOW TIME 

The day of the Kennedy workshop, I had a knot in my 
stomach before people arrived. But as they trickled in, 
first alone and then in groups of two and three, I knew 
it was going to be a good day. And it was. By the time we 
got underway, we had 26 participants in the room. 

TWWs use the stories in ASK Magazine as a starting 
point. At the Kennedy workshop, people began reading 
the story we had given them and silence fell over the 
room. Slowly, as people finished reading, we heard the 
murmuring of conversations starting up in the small 
groups we had set up. 

People read at different speeds, and the sound of 
their voices grew as time passed, until the entire room 
was discussing the stories and leveraging the knowledge 
in the stories to talk about their own work. Lessons 
were continuously being generated and shared, 
generated and shared. 

As I watched people talking at that first Kennedy 
TWW, I realized that the workshops themselves are the 
fun part of my job. The material we present speaks for 
itself once we get participants through the door. Our 
challenge is speaking for the material in advance, so that 
people have the opportunity to experience it. • 
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SPECIAL FEATURE: KNOWLEDGE SHARING CONTINUED 



LISTEN UP 

Carlos Torrez, Ames Research Center 
Transfer Wisdom Workshop November 7, 2001 


O ur division was under a hiring freeze and our 
workload was increasing. We had one person on 
staff who was rarely assigned work on high- 
profile projects because he was thought to be non- 
productive. I decided that it was time to bring this 
person out of mediocrity and into productive mode. 

I believe that all people want to do well and want to 
succeed. I approached my manager with my thoughts 
about this. He laughed and said, "He doesn't have what 
it takes and won't change." 1 pointed out that if we did 
nothing, the workload would continue to rest on a few 
people and our best workers were likely to experience 
some form of burnout. I proposed that I become a 
mentor to this person. 

I began by explaining that I wanted him to succeed. 
I spent a lot of time listening. Soon his work output and 
confidence began to improve. He came by and asked 
frequent questions and proposed possible solutions. 
This "problem employee" often solved his own 
problems as he spoke. By giving him the encouragement 
to extend himself and trust his judgment he seemed to 
blossom. He even went to my supervisor and asked for 
more challenging work! 

Mv supervisor came by, excited, and said he had 
noticed changes and wanted to thank me for doing such 

HOLD HIM, “ALL I DID WAS 
PUT HIM IN TOUCH WITH 
HIS OWN POTENTIAL. HE DID 
ALL THE REST.” 


a fine job being a mentor. I told him, "All I did was put 
him in touch with his own potential. He did all the rest." 

I learned much from this experience: Do not judge. 
Take time to know people and their dreams and goals. 
Listening is often more important than talking. • 


TRUSTING THE ENEMY 

Terri Rodgers, John Glenn Research Center 
Transfer Wisdom Workshop May 2, 2002 


T he opportunity to manage a flight project came up 
and I was eager to see what that world was like — 
to actually see hardware fly. The only catch was 
that the opening occurred because the current project 
manager wanted out. It was too much work on top of his 
other workload, and the project scientist was driving 
him crazy. 

Sure enough, as soon as I took the job, the project 
scientist started complaining all the way up to his 
management chain. We would 
be in a meeting and have to 
step outside to argue over some 
disagreement. Finally I decided, 

"If you can't beat 'em, join 
'em." I started to listen closely 
to his concerns and realized 
that some were valid. I also 
started to recognize his strengths, and I capitalized on 
them. He was quite articulate and he was willing to share 
his ideas with an audience. I asked him to present a few 
charts at our monthly presentation to management. I 
also included him on the telecoms with our payload 
support managers at Marshall Space Flight Center and 
Johnson Space Center. These simple things gave him 
more insight into what was going on with the project, 
and they cost me nothing. 

The project moved along and before too long our 
hardware was tested and ready to fly. It was time to 
present our work to management during a two-dav 
review. The project scientist faded into the background 
because he trusted me to do my job. The first part went 
fine. I went home Friday evening, thinking about what I 
would say on Monday. But things didn't work out the 
way I planned. I was eight months pregnant, and I went 
into premature labor. I called work to say that I wouldn't 
be in on Monday. 

When Monday came, the project scientist did a 
wonderful job presenting my charts — but not before 
praising me for the job I had done. This from a person, 
who looked more like an enemy than a friend when I 
first met him. You can go far when you reach out to 
"enemies" and listen. • 
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GET IN BED 

Jon Bauschlicher, Kennedy Space Center 
Transfer Wisdom Workshop January 23, 2003 


D uring a long and checkered professional career, 
I was taught to "never get in bed with the 
customer." While working for the government 
(NASA and US Air Force), "getting in bed" with the 
customer/supplier would, at worst, compromise your 
objectivity and result in a conflict of interest, and, at 
best, give the appearance of impropriety. 

While working in private industry, we were told that 
"getting in bed" with the customer/supplier would reveal 
minor flaws in your product or process that the 
customer didn't really need to know about. We were told 
that the customer would nitpick you to death with 
questions and concerns that weren't important, and that 
decision-making would be delayed by bringing someone 
else into the decision making process. We were told that 
proprietary products or design processes would be 
revealed to someone without a "need-to-know." 

One project changed my feelings about all that. 
Project KAFFU (Kiwi Air Force Fighter Upgrade) was 
a fighter retrofit program for the Royal New Zealand 
Air Force; we were trying to give F-16 capabilities to 
old A-4 fighter aircraft. When the contractor I was 
working for won the competition, the contract 
included sharing office space with the Royal New 
Zealand Air Force engineers, pilots, and maintainers 
throughout the entire development, prototype, and flight 
test effort — cradle-to-grave, as far as the engineering 
effort was concerned. 

We sat side-by-side with these guys. They partici- 
pated in every facet of the engineering development 
program. They helped write requirements, software, 
drawings, specifications, test plans, test procedures and 
test reports. They worked in the lab integrating and 
testing hardware and software. They knew how things 
worked, and they saw things fail. They saw smart and 
dumb engineers and managers. They worked and played 
with all of us. Aside from a few classified areas, they had 
full access to our entire facility — our engineering labs, 
work areas and our cafeteria. 



They were truly, fully, integrated into our 
engineering team. And the results? 

We had product advocates (the Royal New Zealand 
Air Force engineers) who were trusted by both the 
customer (the Royal New Zealand Air Force) and the 
supplier (us). With less engineering work for us, we 
produced a product that more fully addressed our 

THEY WERE TRULY, FULLY 
INTEGRATED INTO OUR 
ENGINEERING TEAM. 


customer's needs and requirements. It was a better 
product — more capable and user-oriented — than we 
would have produced without the active participation 
of the customer's engineers, operators, and maintainers. 
And, in the end, we had a well-informed, well-educated 
customer expert in our system's uses and capabilities. 

Overall, the results from "getting in bed" with the 
customer were nothing like l had been taught they 
would be. Nothing but good came from the effort, and 
both customer and supplier benefited — the ultimate 
win/win situation. • 
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PROJECT jVJ n J 1 R BE jVj E NT: 



Contrary to ujhat my mife ujould say, I don’t uuatch 
much television. I do, houuever, regularly uuatch one 
shorn on the Learning Channel — the reality series 
called Trauma: Life in the E.R. 


While watching the last episode, I recognized 
parallels between what was going on in the emergency 
room, with its host of accident and gunshot wound victims, 
and what goes on in successful project management. 

Inside a Metaphor 

First, there was a sense of urgency, but not haste. 
As an ambulance or helicopter brought in patients, the 
physicians, nurses and technicians did some quick 
planning, anticipating the likely condition and needs of 
the patient. They moved to get the necessary tools and 
equipment in place before the patient arrived. 


Once the victim appeared, there was no wasted 
motion. With time as the chief resource, no one did 
anything that didn't directly address the ultimate 
objective — saving the victim. The medical team shared 
a clear set of priorities: deal with life threatening issues 
first, possible long-term consequences second and 
ignore everything else. 

Each person in the room had an active role. No one 
was in the emergency room as an observer or overseer. 
Someone was clearly in charge, but typically no one 
waited to be told what to do. Interestingly enough, no 
one ever seemed paralyzed by fear of doing the wrong 
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thing. Through training and experience, the entire 
team operated in harmony. When there wasn't enough 
information to make a decision about a course of 
treatment, the staff moved quickly to get more informa- 
tion using x-rays, magnetic 
resonance imaging and similar 
diagnostics. People spent little 
time debating or pondering 
what to do next. They decided on 
what to do and got on with it. 

Sometimes the unexpected 
happened and a situation that 
seemed to be in control 
suddenly went out-of-control. 

In those cases, there was 
no hand wringing or fault 
finding — -just a measured, 
adapted response to the new 
situation. Sometimes there 
were mistakes; mostly they were 
acts of omission rather than commission. There was 
concern and open discussion about the mistakes, but 
learning was the chief consequence. 

I also noted that there was a general acceptance that 
not everything affecting the patient was totally within the 
control of those in the emergency room. The staff 
spent their time dealing with what was in their control 
and not complaining about what wasn't. 

Rerun 

I know some of you are thinking that I have carried 
this metaphor too far. Perhaps so — perhaps not. 

Consider planning and preparing for the project. 
It's important to do it, but a team shouldn't spend too 
much time trying to achieve perfection. The plan will 
never perfectly reflect reality. And what about priorities? 
Certainly a project's priorities are likely to be less 
clear-cut than those in an emergency room, but having 
them and working to them is no less important. 

Think about economy of resources. It's important to 
have the right number of people working the project, but 
each must have an active role. Like the emergency room, 
a project has no place for bystanders. 

Expending effort on the niceties when the 
fundamental objective is in question doesn't work. From 
what I know of project management, the expression 
“Nero is fiddling while Rome burns" is alive and well. 
Recall from your own experience what happens when 
a project begins to go awry. Lots of meetings, lots of 


analyses and lots of discussion — all aimed at deciding 
on the “right" thing to do. We accept that as a matter of 
course, but should we? 

What's wrong with making a rapid decision based 
upon the data at hand, 
intuition and experience; and 
then, having made the 
decision, focusing our energy 
on execution? Let's face it, a 
perfect answer for any project 
emergency doesn't exit. Yes, 
there are some fundamentals 
to consider, but never a back- 
of-the-book answer that 
prescribes the solution. 

And finally, how do we 
deal with mistakes in project 
man-agement? They are 
inevitable, you know. Any 
project manager who claims 
to have never made a mistake is either a neophyte or a 
liar. Sometimes our mistakes result from things we do 
or don't do when we should have known better. Other 
times our mistakes are only retrospective mistakes — 
mistakes because of factors we could not have known or 
anticipated. 

In either event, we should deal with our mistakes 
and those the folks working for us make in the same way 
as the emergency room does. Admit the mistake. Distill all 
the learning from it we can. Move on. Like the emergency 
room staff, the alternative of avoiding mistakes by doing 
nothing simply isn’t in our playbook. • 


"In order to provoke unconventional 
thinking, you need to create a situation 
where the status quo won't get you 
there," says TERRY LITTLE of his man- 
agement style. “Until you're able to turn that light on in 
people's heads that just doing things the same old way 
isn't going to get you to where you need to be, you're not 
going to stimulate innovative, creative thinking." 

Little is currently the Director of the Kinetic Energy 
Boost Office of the Missile Defense Agency. Before 
that, he was the head of the Air Force's Center for 
Acquisition Excellence. He is one of the Air Force's 
most seasoned program managers, and was promoted 
to Senior Executive Service in 1997. 


Let’s face it, 
for any project 
emergency there 
is no perfect 
ansLuer. 
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AGAIN AND AGAIN AND AGAIN 



W!z 




RECENTLY I HAVE SAT THROUGH A VARIETY OF PROJECT CRITIQUES 
AND HAVE ASKED THE TEAMS INVOLVED TO ARTICULATE THEIR 
LESSONS LEARNED ON THEIR PROJECTS. DURING THESE REVIEWS, 
MY ANXIETY LEVEL AND BLOOD PRESSURE INVARIABLY INCREASE 
BECAUSE I HEAR THE SAME LESSONS LEARNED, REPEATED AGAIN 
AND AGAIN FROM EACH TEAM. 


I WANT TO SCREAM, "I LEARNED THESE LESSONS 30 YEARS 
ago. Why do we continue to learn these same lessons 
over and over again?" I don't scream, though; I remind 
myself the individuals are probably experiencing these 
lessons for the first time. I've come to realize, too, just 
about all the repeated lessons reduce down to just 
one primary lesson: Project scope drives project cost 
and schedule. 

Said another away, if you properly define and gain 
alignment to your project scope early in the life of your 
project, the cost and schedule will follow. 

I love the scope but hate the cost!!! 

I was the project manager on a project and was called 
into a Friday afternoon meeting to review the project's 
cost, scope, and schedule. I used my traditional agenda 
of scope review, cost review and schedule review. During 
the scope review, I discussed the base scope (i.e. scope 
required to meet the business requirement) and the 
value-added scope (i.e. savings-justified scope, which is 
discretionary but improves the economics of the overall 
project). The scope review went extremely well. 


Next we talked the cost of this scope. The reaction 
was, "I love the scope but hate the cost." My response 
was if you like the scope, then this is the cost. We went 
back and forth on this point for the next twenty 
minutes and at the conclusion of a robust discussion, 
we agreed to the proposed scope but disagreed on the 
cost to be presented to top management the following 
Monday. We did agree to mull over the scope and cost 
data and reconvene on Monday morning to review our 
positions again. We met at 7 AM on Monday and 
agreed to use my cost figure in the subsequent 
meetings with hierarchy. The figure was used, the 
scope was installed, and the job came in slightly below 
the stated costs. 

This experience reaffirmed my belief that if you get 
the scope correct, the costs will be correct. As I sit 
through other project critiques or learn a project's 
costs are trending high or low, the root cause I ask the 
team to address is how their original scope basis has 
changed. Without exception, changes in scope bv the 
team and/or their hierarchy directly relate to changes in 
cost and schedule. 


by W. Scott Cameron 







I want this cost but need that scope 

We started to design and construct a "grass-roots" 
manufacturing facility and planned to complete the 
multi-million dollar project several years later. 
Unfortunately, just how many millions of dollars the 
plant was going to cost became extremely troublesome. 

Early in the life of this project, management believed 
the project should cost $X, a figure based on their collec- 
tive experience and not on the project's scope. Agreement 
to proceed with the project and its staffing was based on 
their $X cost figure. A subsequent conceptual study, 
however, indicated that the project's cost could be as high 
as $X + 40% based on the defined scope. 

Management declared this estimate unaccept- 
able. They questioned the cost engineer's credibility, 
even though he was quite experienced and had used 
proven methods to develop the estimate. Accusations 


size, a key piece of process machinery could no longer 
fit, so the building had to be returned to its original 
dimensions. Despite valid scope additions, management 
refused to approve project change authorizations. They 
said, "You already have 20% more funding than you 
need. We're not going to give you more fat!" 

Once management ignored valid cost estimating 
and trending data, the project team didn't bother 
much with cost control. The situation soon got out 
of hand. The project team knew they were exceeding 
their funding commitment, but since management 
refused to listen to the team's concerns and data, 


SINCE MANAGEMENT REFUSED TO LISTEN TO 
THE TEAM’S CONCERNS AND DATA, COST 
CONTROL WAS INEFFECTIVE. 


flew that the scope and estimate were "gold-plated." 
After agreeing to reduce the project scope to appease 
management (for example, reducing the building 
size), a compromise estimate of $X + 20% was 
reached by agreeing to eliminate or change specific 
scope items. 

After receiving project funding, however, the elimi- 
nated/modified scope was restored because the 
reduction decisions had been based on cost criteria 
alone, with no real consideration of the actual needs 
of the project. For example, by reducing the building 


WITHOUT EXCEPTION, CHANGES IN SCOPE BY 
THE TEAM AND/OR THEIR HIERARCHY DIRECTLY 
RELATE TO CHANGES IN COST AND SCHEDULE. 


cost control was ineffective. 

So the required scope grew while the cost predic- 
tions stayed the same. When the project team 
completed definition and design, a second estimate was 
published at $X + 25%. During construction, the 
estimated cost of the plant increased to $X + 40% (note 
the amount the conceptual study estimated at the 
outset of the project). 

At project close, the project team had done an 
excellent job of designing and building the plant. The 
start-up was on time and one of the best in company 
history. Cost was the only criterion the project failed to 
meet. Once again, the same lesson learned: Project 
scope drives project cost and schedule. 

We continue to learn this lesson over and over 
again. One day I may just scream! • 


SCOTT CAMERON is the Global Capital Systems Manager for the Food & Beverage Global Business Unit of Procter 
and Gamble Company in Cincinnati, Ohio. For the past 20 years, he has managed capital projects and 
developed other capital management practitioners for Procter & Gamble within its Beauty Care, 
Health Care, Food & Beverage and Fabric & Home Care Businesses. 

In an interview last year {ASK 7), Cameron reflected on his tenure as a project manager: 
"When 1 think about how I have grown throughout my career, I can talk about the projects that I've worked on. But 
when I get down to the root cause of my growth and development, the most important factor has been the people who 
managed, coached and challenged me. Individual managers have had a profound impact on me. As I look back, I can 
see how this boss taught me how to write proposals. This mentor taught me financial aspects and cash flow of the 
company. This peer focused me on schedules. This one focused me on team dynamics. This one taught me how to 
listen and not immediately react. A collection of people helped me become the manager I am today, and now I feel 
that it's part of my job to share my experience with younger managers the same way that others invested in me." 
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Grins <£. Giggles 

The Launch Pad to High Performance 


By Maj. Norman H. Patnode 


Long ago I observed that people get more things done when 
they're having fun. At the time, I had no idea why. Now I think I 
have an answer. When children play, look at the energy that's 
put into it, that’s shared with everyone else. This sort of energy 
brings people together, unleashes their creativity and indeed 
inspires them to do amazing things. To steal a phrase from Dr. 
Owen Gadeken's article in ASK 7, it's their "activation energy.” 
Amazing stuff! Dr. Gadeken highlighted the need for activation 
energy to propel a team to high performance. I'd like to focus 
your thoughts on creating this energy. 
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After years of experience with teams. I've come to 
recognize the absolute necessity of grins and giggles — of 
having fun. This is hands-down the best way to create 
the activation energy needed to move a team forward. I'm 
so convinced of this that when I join a team, if it's not safe 
to have fun, I work to change that. In whatever way 
possible, no matter how stilted or silly, it's essential to 

As a team moves 

towards higher performance, its 
members begin to see the differ- 
ences between themselves not as 
obstacles, but as opportunities. 

inject humor into a team's work, and the earlier the better. 

Once when I joined a small team of engineers who 
were responsible for managing tests of reentry vehicles, 

I found myself surrounded by people who were not 
having fun. They would frequently, after getting off the 
phone with a customer, begin to rant and rave about 
how stupid the customer was and how much trouble the 
customer was causing them because of some new 
funding or schedule change. 

Mv solution? I brought a toy plastic dart gun to 
work. Whenever one of my teammates began to rant and 
rave, I grabbed my gun and shot him, over and over until 
he shut up. At that point the whole team was gathered 
around, and after we all quit laughing at the ridiculous- 
ness of the spectacle, we began to talk about the 
problem and what we could do about it. In a matter of 
weeks, the attitude of the team had shifted. We began to 
work together and to focus on how we could make our 
jobs easier by making our customers' jobs easier. 

And the dart gun? Believe it or not, within a couple of 
weeks everyone had one, and we continued to use them as 
a fun way to blast the negative energy out of our team. 

Fun doesn't have to be this dramatic. The key is to 
bring people together — so that they can share, explore 
and have fun. This can be done with something as 
simple as a lunchtime card game. 

I still remember one of my earliest team experiences. 
Fourteen of us were doing stability and control work for 
high-speed military aircraft programs. Most of us were 
young, right out of college, which meant we were 
strapped for cash. We ate our sack lunches each day as 
we sat at our desks and reviewed reports or read technical 


journals. All that changed the day that Paul, a 
senior engineer in our group, brought in a 
couple decks of cards and herded us into the 
new central conference space. " Bring your 
lunch," he said, "we're gonna have some 
fun." We were a little apprehensive — was 
this allowed? 

After assuring us that we weren't 
breaking any rules, he said we were going to 
play Hearts, and he started explaining the 
rules. We ate, played and kept score. More 
importantly, we started talking to each other. 

Just in that first day I learned that Bill raced his 
car on Saturdays at the local drag strip, Jose had a 
girlfriend in Toledo and Joe was taking classes at 
night in hopes of getting into medical school. It was fun, 
and we agreed to play again the next day. 

Pretty soon we were competing for bragging rights. 
Then one day, after Bob had won several days in a row, 
it happened — we ganged up on him. While it's true we 
"ganged up" on him, what really happened was we 
started working as a team. Looking back on it, I realize 
that as we got to know each other, it became much 
easier to ask those "dumb questions," and to ask the 
team for help when we needed it. We also got a lot better 
at working together, solving problems, and getting 
things done — all because of a silly card game. 

If it hadn't been for those card games, I'm sure none 
of us would have made that three-hour drive to Toledo 
seven months later to see Jose and Lori get married. 

Fun comes in many shapes and sizes, but one of the 
best ways to bring on those grins and giggles is to tell a 

In whatever way 

possible, no matter how 
stilted or silly, it’s essential to 
inject humor into a team’s work, 
and the earlier the better. 

good story. We ail recognize how much learning can be 
found in a good story, but we shouldn't neglect the fun 
that can be squeezed out of one, as well. On one of my 
more recent teams, we made a point to share our stories 
in a fun and humorous way. 

Every Friday afternoon we'd meet in the courtyard 
for refreshments, a much-deserved break, and the 
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Owen Gadeken and Maj. Norman H. 
Patnode met in January 2000 when 
Gadeken was the faculty advisor to 
Patnode's section in the Defense 
Acquisition University’s (DAU) 
Advanced Program Management 
Course. "Although Norman sat in the 
back corner of the room, he was not 
shy about commenting on virtually 
anything that caught his interest 
during the course," remembers 
Gadeken, whose article in ASK 7, 
"Activation Energy," brought out 
the "Grins and Giggles" in Patnode. 
Says Gadeken: "Whenever I had a 


particularly dry or even complex 
subject to discuss with the class, I 
could always rely on Norman to come 
up with some interesting insight on the 
topic.” Gadeken soon discovered that 
Patnode also had a well-developed 
sense of humor, probably honed from 
the experiences he relates in his 
article. Eventually, with Gadeken’s 
encouragement, Patnode joined the 
DAU faculty. "I continue to be 
amazed," says Gadeken, "at the 
insights Norman can draw from both 
his and others’ seemingly routine 
project management experiences." 


MAj. NORMAN H. PATNODE 

is a Professor of Program 
Management &. Leadership 
at the Defense Acquisition 
University, where he provides 
training in strategic leadership, critical 
thinking, teamwork and teambuilding, the 
application of Myers- Briggs (MBTl), program 
risk management, coaching and conflict 
management. He also teaches a number of 
the basic program management tools. He can 
be reached at norman.patnode@dau.mil 



presentation of what we called the "Clue Bird" award. 
(A "Clue Bird," an expression used by pilots in the 
military, is a good luck sign because it lands on one's 
shoulder when one needs it most.) The rules were 
simple. Anyone could get up and tell a story about 
someone on the team. Usually the story involved some 
"noteworthy" activity from the previous week, such as 
how Dan had become a hero by screwing something up 
in a way that caused the rest of the team to take note of 
an impending disaster, and avert it. 

This was a big team, responsible for the Herculean 
task of manufacturing and delivering the Air Force's 
newest large cargo aircraft, so there was never a shortage 
of stories each week. The stories were always clean and 
in good taste, but since it was widely accepted that only 
10% truth was required for a good story, they always 
brought plenty of comic relief. 

After everyone had told their stories, we'd all vote by 
applause and the "Clue Bird" would be passed on to the 
winner to display proudly at their desk for the week. As 
we all headed back to our desks, laughing and reflecting 
on the stories we'd just heard, and what we'd learned 
from them, you could actually feel the increased energy 
in the team. 

The thread that weaves these three examples of 
teams sharing grins and giggles is the very fact that they 
were "sharing." Shared experiences create space where 
team members can get to know one another, and 
discover how much they have in common with each 
other. These commonalities are the building blocks of 


trusting relationships. And trust is the foundation 
required to build a high performance team. With a high 
performance team, you can accomplish anything. 

As a team moves towards higher performance, its 
members begin to see the differences between 
themselves not as obstacles, but as opportunities. 
Exploiting these opportunities leads to more innovative 
ideas and increased performance. Team members learn 
to move past superficial differences in how they look 
and speak, and begin to recognize the differences in how 
they think, explore and even dream. They find new and 
creative ways to put those differences to work for the 
team. As a result, performance soars. 

As for the team members, they'll tell you they're 
having the time of their life. They'll tell you what they're 
doing is fun, not work. Then they'll make you swear not 
to tell anyone. So don't. Just keep on grinning. • 

Lessons 

• Work can and should be fun. Think about a child at 
play — curious, open-minded, learning and discovering. 
Play can stimulate a cycle of solving problems and un- 
covering new ones by bringing out the best in each of us. 

• Regardless of your position on the team, you can 
create the fun and energy needed to launch your team 
on a path to high performance. 

Question 

If not by play, what ways do you tap the " activation energy" of 
a project team ? 
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practices by Gerald Murphy 
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> > > THE BIGGEST CHALLENGE IN MANAGING SCIENCE 

■ I 

INSTRUMENT DEVELOPMENT OR ANY NEW TECHNOLOGY 

DEVELOPMENT FOR THAT MATTER IS TRYING TO GET THE 

PROJECT COMPLETED ON SCHEDULE FOR THE MONEY YOU 

HAVE. FEW PROJECT MANAGERS ACCOMPLISH THAT, & 

DESPITE WHAT THEY MIGHT TELL YOU. 








PRACTICES CONTINUED 


It just doesn't happen, and it's easy to understand 
why: technology development doesn't have a predictable 
path. You haven't built this thing before so how the heck 
do you know how much it's going to cost, and, besides, 
you can't foresee all the problems you'll run up against. 
You know the result you want and you declare success 
when you are "close enough." In short, the job must be 
"dynamically" managed. 

When I worked on the Advanced Composition 
Explorer (ACE) project, we needed to produce five 
instruments that were either entirely new or were 
considerably modified from earlier models. These were 
each $8-10 million instruments. All of them were what I 
would call technically risky in one way or another — 
some in several ways. 

Some of our problems early in the project derived 
from not understanding exactly what the instruments 
were intended to do (what was going to be good 
enough), and not knowing what we could do to help the 
university-based teams in building them. We in the 
payload management office took the approach of asking 


each team, "What do you need in order to get your job 
done, and how can we make that happen?" 

As a cure for this problem, one of the things that we 
decided to do was to have Implementation Reviews. I 
had never been on a project before where this was done, 
but it turned out to be the single most valuable review 
we had from the point of project success. 





Typically, reviews are design-focused. In point of 
fact, many of a project's problems are not due to design 
flaws. They are due to implementation flaws — if the 
implementation doesn't have a good "design," it will not 
be executed smoothly. 

When I use the word "implementation," I mean it in 
the broadest sense: implementation of the 
design and manufacture of the 
instrument. And I don't just mean taking 
a look at schedules and money; I mean 
looking to see, as well, if you have the 
right team, if the team is assembled in 
such a way that the lines of responsibility 
make sense, if the interfaces are clear and easily defined. 

Do you have margin for error? Where are the 
technical risk items and what is your plan to deal with 
them? Who is responsible for what? How many 
engineers do you have on this job and do they have the 
right experience? Oh, you have five engineers? Well, I 
only see three engineers in the room; where are the 
other two? "Well, they actually work for Joe Blow, a 
scientist down the hall. Joe has promised me that a year 
from now, when I need the engineers, I can have them." 
Yeah, right, but what happens if Joe decides he needs 
them in a year? They actually work for him, right? 

Here's another example: On one project, an 
instrument team partners with a team from the 
European Space Agency (ESA). A foreign scientist there 
tells his American counterpart, "I can give you an 
electronics board or part of your detector system and it 
will do all these wonderful things, and you won't have to 
pay for it out of NASA's budget because ESA will pay for 
it." The American scientist says: "That's great; that 
makes my instrument cost a half million dollars less." 


> > > I HAD NEVER BEEN ON A PROJECT BEFORE WHERE 
THIS WAS DONE, BUT IT TURNED OUT TO BE THE 
SINGLE MOST VALUABLE REVIEW WE HAD FROM 
THE POINT OF PROJECT SUCCESS 
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FROM LEFT TO RIGHT, A TRIO OF ADVANCED COMPOSITION EXPLORER INSTRUMENTS: 

SOLAR WIND IONS MASS, SOLAR ISOTOPE AND SOLAR WIND ION COMPOSITION SPECTROMETERS 


But what happens, a little way down the line, when 
ESA is a little slow to fund its part of the project, or 
erratic currency exchange rates cause a financing 
problem or a new tariff regulation prevents the transfer 
of technology from one side of the Atlantic Ocean to the 
other? These are examples of implementation 
questions. It may still turn out that having ESA 
supplement the program is the right thing to do, but you 
have to ask the questions. 

The point of the implementation review is to 
prevent problems from occurring later by tiying to get 
our arms around the planning from the start. Our 
discussion might go like this: "Well, look, instead of 
having that scientist across the ocean be solely 
responsible for delivering this critical element, maybe we 
can find some other way to get it." Or we might decide 
to fly there and observe first-hand how well our 
counterparts are doing, and if there is something we can 
do to help assure success. 

For the ACE project, we traveled around to each 
pannering institution. The process took several months 
because we would camp out onsite for three days. We sat 


around the table together, listened to presentations and 
figured out how we were going to get the instrument 
built and delivered. We found the holes and looked for 
ways (together) to plug them. We tried not to be 
optimistic and fool ourselves. 

The size and composition of review teams were 
tailored to the places we went. It was always tricky 
putting together just the right team, but A1 Frandsen, 


GERALD (GERRY) MURPHY founded Design Net engineering in 
1996 as a network of senior consulting engineers 
% serving as "problem solvers" for NASA missions. The 
network evolved into an aerospace hardware/software 
r W development company providing design and fabrica- 

tion service to businesses, universities, and govern- 
ment agencies. About his world since leaving NASA, he says, 
"Managing with flexibility is still my paradigm. In fact, it works in small 
business environments even better than when you are managing the 
standard NASA project. In either case, the ground under your feet is 
always in motion, and fog in the road up ahead never quite “clears.” 



our payload manager, was good at that and we managed 
to find the expertise that we needed. 

The review teams turned out to be between five to 
eight people, a balance across the different disciplines, 
and they included the payload group (i.e. A1 Frandsen, 
Howard Eyerly, our Reliability and Quality' Assurance 
Manager and me). Say we knew that a team was having 
a problem making their detector meet 
launch load requirements. We would grab 
somebody from JPL who could solve that in 
a week instead of letting the instrument 
team spin their wheels for six months. In 
addition, we would typically bring someone from 
Goddard who was good at understanding resources and 
estimating actual costs. 

The implementation review happened only once at 
each site, but it was a big deal. I would say it was the 
most important thing we did to enable ACE to deliver on 
schedule and within budget, because we recognized and 
dealt with potential problems before they became 
unmanageable and costly. 

Since then I have seen several projects that would 
have benefited from this review. It is important that it 
take place at the right time. You have to understand 
your requirements, your schedule, and your other 
resource constraints. You also have to understand 
where you have flexibility. If the review is too early, it is 
not beneficial; if it is too late, you are buried in trying 
to solve the problems of the day instead of being ahead 
of the wave. 

Implementation reviews do one other thing. They set 
the tone for management of the project. They establish a 
teaming relationship (if they are run properly), and they 
level the playing field instead of setting up turf wars. • 


> > THE SIZE AND COMPOSITION OF REVIEW TEAMS 
WERE TAILORED TO THE PLACE WE WENT 
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INTERVIEW 



Dr. Michael Hecht 


Dr. Michael Hecht has been a member of NASA's Jet Propulsion Laboratory (JPL) 
staff since 1982. He is currently Project Manager' and co-investigator for the Mars 
Environmental Compatibility Assessment (MECA) 


Developed for the 2001 Mars Surveyor Lander, 
MECA is a miniature chemistry, microscopy, and 
electrostatics laboratory. MECA was chosen by NASA 
from a field of 39 proposals and was developed to 
perform studies on the potential hazards that the soil 
and dust on Mars might pose to human explorers. (The 
MECA project was featured in an earlier article by Dr. 
Hecht in ASK 7.) 

In his previous assignment with NASA's New 
Millennium Program, Dr. Hecht was instrumental in 
defining the "microlander" that was adopted as NASA's 
New Millennium Program Deep Space 2. Beginning in 
1991, he led a microtechnology program at JPL's 
MicroDevices Laboratory. 

Dr. Hecht was the first recipient of JPL's Lew Allen 
Award for Excellence, which was established in 1 990 to 
recognize and encourage significant individual accom- 
plishments or leadership in scientific research or techno- 
logical innovation by JPL employees during the early 
years of their professional career. He has published 
extensively in both the surface science and the planetary 
science literature. He received his Ph.D. from Stanford 
University in 1982. He has also been a member of the 
ASK Review Board since ASK 1 . 


A couple of years ago, you gave a conference presentation 
about a science instrument, MECA, that was going to fly 
on a Mars mission. You described yourself as both the 
project manager of the instrument team and the co- 
investigator. It's unique for a project manager to be 
involved so directly in the science of a project. Why are 
these normally kept as separate functions? 

Generally, there is the concern — and it is a legitimate 
one — that someone who has an investment in the scien- 
tific return isn't going to be able to control the 
resources. At my institution, JPL — and I think at NASA 
in general — you'll find there's a creative tension between 
the science team on a mission and the project team. The 
model is that the science team pushes the capability, 
while the project manager holds the line and protects the 
resources. The science team will come and say, "We want 
more memory so we can do more analysis on the ground 
and return better data," while the project manager will 
say, "that will push the budget or schedule." Allowing a 
scientist to also have a project management role is 
generally viewed as the equivalent of letting the fox 
guard the chicken coop. 
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But MECA was different. How so? 

MECA was a very unusual project. We were below the 
radar, if you will, so we could be a little more relaxed. 

What kind of relationship did you have with the 
Principal Investigator (PI), someone you were working 
with closely as a scientist and at the same time managing? 

On MECA, the principal investigator was expert in the 
general scientific issues we were studying, hazards 
associated with particles. He was a senior guy, very 
skilled and very knowledgeable, from whom I have 
learned a tremendous amount. But he knew almost 


mission. The other job, frankly, is a day-to-day science 
management job. Most people in this community 
recognize that once you get past winning the proposal, 
its more important to have a science manager than it 
is to have a statesman. 

How does your background as a scientist, or researcher, 
help you as a project manager? 

To me, the science is part of the whole system. When 
you optimize the system, the science is one of the factors 
that you can weigh. I'll give you a very simple example. 
This happened with MECA when we had an opportunity 






nothing about Mars science, so that was really my role. I 
, was the one defining the Mars science agenda. 

When we have a discussion about who should be the 
principal investigator for an instrument or a mission, we 
recognize that there are two different jobs of the PI, and 
you seldom find an individual good at both of them. One 
job is to be the statesman, the spokesman, the senior 
individual with unimpeachable scientific credentials, who 
stands up in front of the cameras and speaks for the 

| 

i 


to add a component, a stirring device that would accel- 
erate chemical reactions. Now, the reaction of the project 
manager of the overall mission was, “You're adding 
capability to the instrument." My reply was, “By doing 
this we can finish the experiment in one day instead of 
two days. We won't have to deal with an overnight freeze 
and thaw cycle, which not only imposes risks, but adds 
a great number of requirements on testing, specifically 
environmental testing." 
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INTERVIEW CONTINUED 


While I'm considering the science and engineering and 
project management as part of the overall risk picture, 
I have a different perspective than someone who is only 
treating the issue as a requirements driver. 

Does this sensibility, being a scientist/project manager, 
affect how you select your team? 

We all have a model of the kind of person we want 
working for us, and it often mirrors our own abilities 
and interests. That "sensibility," as you want to call it, 
defined mv choice of all of our staff. On MECA I put 
the kind of team together that I could work with. I 
drew on a group that JPL likes to call "technologists," 
a group it doesn't normally look to for mission work. 
By technologists, they mean scientists in disciplines 
other than space science. That's not pejorative; it's just 


train them in my management style. So, I had a team 
of generalists, and I think that's why it worked. I think 
that everyone felt like they could do any job on that 
team. They had an assigned job and they accepted that, 
but only because that was what had been negotiated. 
If tomorrow we changed the agreement, they could have 
stepped into a different role. 

Was it difficult to convince people without flight 
experience to join the project? 

It varied with each person. Of the hundred or so PhDs 
in the MicroDevices Laboratory, I have probably 
approached thirty of them with such an opportunity at 
one time or another. Of the thirty, perhaps five or six 
jumped at the opportunity. That's why they came to JPL, 
they told me. They'd always wanted to do space work, 
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terminology, nothing more. You could have a Nobel 
Prize-winning biochemist and JPL wouldn't put him in a 
science category. 

These were people that I had worked with for 
years, and years, and years. Many of them were physi- 
cists or chemists. I tend to be fond of physicists 
because I am trained in physics. The organization 1 
came out of is called the MicroDevices Lab. We had 
people who are electron microscopists or spectro- 
scopists, people who study the arrangements of 
atoms on surfaces. In fact, that's what I did most of my 
career. I studied surfaces and interfaces, semicon- 
ductor materials. 

Mv model for project management was the one 
I learned from hanging around small businesses. If 
someone is too busy to finish this job, the person at the 
next desk will finish it. Laboratory scientists are good at 
working this way, and have an instinctive grasp of the 
trades involved in defining the instruments. I thought it 
was easier to take those very bright, PhD scientists and 
train them how to do mission work than it was to take 
the people who typically worked on flight projects to 


they'd always wanted to build things to fly; they never 
knew how to go about it, and they were completely 
isolated from the flight culture at JPL. 

Did anybody think you were managing the project in an 
unorthodox way by building a team of “generalists''? 

I don't know. But one of the most interesting conversa- 
tions I had when MECA started was with the fellow who 
was the section manager of the MicroDevices 
Laboratory at the time. He was concerned about what I 
was doing because he worried that once those people 
went to work on a mission, they would never want to 
come back into research. "Why is that so terrible?" I 
asked. I think it's a good thing for a research organiza- 
tion to have turnover — and for us to have alumni in the 
larger JPL community. 

In the end, it turned out every one of them went 
back to research afterwards, but I think they all felt that 
they came back to their research with a broadened 
perspective. The flight world gives you street smarts 
about how to get things done on schedule and to cost 
that you never learn in the research lab. 
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Back to the conference we mentioned at the start of the 
interview. I remember you walked into the lobby one night 
and said that you had gone outside to look at Mars. Is that 
frontier aspect of it something that means a lot to you? 
Yes, absolutely. I have to admit that is something that's 
fairly recent. That is something that has developed within 
the last decade, at most, that kind of passion for Mars. 

And what is the source of it? 

Several things, one of which I suppose is that I'm turning 
50 this year. I also think it is far more common at JPL 
than almost any place at NASA to find that kind of 
passion. You find people who come to do jobs all over 
JPL — in contracts, in the machine shop, as scientists, as 
engineers — and they tell you, "I know I could have made 
more money in private industry, but I just fell in love 
with the idea of going out and exploring the solar 
system." That's very common. 


Could you imagine being the project manager of a project 
that didn't allow you the freedom you had on MECA? 

I don't know. I imagine that if I was on a project where I 
wasn't able to select the kind of people I wanted to work 
with, the experience would be much less satisfying to me. 

Is it fair to ask which of these two f science or project 
management r matters the most to you? 

If I have to choose whether my career is going to be in 
project management or in science, for me that's a very, 
very difficult choice. 

Let me ask you one other question. You r re on the ASK 
Review Board , and you participate in the Masters 
Forums. What's the value of the Knowledge Sharing 
Initiative for you ? 

One of the most important messages you learn here is 
that as you delve into project management more deeply, 
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You began your career as a researcher \ and then moved 
into project management. Was that a way for you to get 
to Mars? 

Not entirely. 1 enjoy wearing a lot of different hats. 
I've slowly come to realize that this is something that 
drives me. I want to have some experience in every part 
of this process, basic instrument concepts through 
instrument development, through the actual building 
of flight instruments where I have done my project 
management, and through the study, the science of 
what I learn, both the data from the instrument 
and the modeling and theory. I've been driven to be 
that broad generalist. The only place in that whole 
chain where there is a conflict, an artificial conflict 
imposed by the institution, is in the role of science and 
project management. 


you realize the idea that anyone is doing it to a blueprint 
is ludicrous. Nobody uses a blueprint. 

Certainly every time I come to the Masters Forum, 
or read ASK, 1 come away with having learned 
something. I should say not just new tools, but new 
perspectives. I think learning, and not just learning other 
ways of doing things, but learning to have realistic expec- 
tations is very important. It is just like raising children. 
Mv first one was six years old before we had the second 
one. You somehow expect the second one will be like the 
first. Of course, they never are. They couldn't be more 
different human beings. I'm sure if we had a third the 
same thing would happen. 

I'm at that stage in project management where I 
need desperately to learn that lesson. If I go in expecting 
the next project to be like the previous one, I will not 
only be severely disappointed, but I could very well fall 
flat on my face. • 
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Tributes to Frank Hoban 



On December 5, 2002, NASA lost one of its stars, Frank Hoban. Recipient of the NASA 
Exceptional Achievement Medal and the Apollo Achievement Award, Hoban ended his 
NASA career as director of the Project Management Initiative. In 1997, he published a 
book about his NASA career, Where Do You Go After You've Been to the Moon? 


I first met Frank the day after I was assigned to form 
a Space Station task force. Frank stopped by my office to 
say that he knew we would need someone to look after 
management, and he was interested in the job. I liked his 
style, and I gave him the job on the spot — probably the 
best program decision I ever made. 

We discussed the organization we needed for the 
task force, and realized that we couldn't afford to go 
through the usual advertising and selection. So, Frank 
personally persuaded the best and the brightest to join 
the program. It was a great outfit, and we had a lot of 
fun — thanks in large part to Frank's efforts. (Everyone 
remembers the summer parties that we had at his farm 
in Northern Maryland.) 

To the end, Frank excelled at making people want to 
take part in whatever he was working on. We will miss 
you, friend. 

John Hodge 

It was often said of Frank that he had an "idea a 
minute/' and many of them were exceptional. But the 
most important example Frank set for us was his 
marriage to his beloved Mary Louise. Although married 
for decades, they remained as giddily in love with each 
other as a pair of high school sweethearts. I remember 
when Frank was still working at NASA headquarters, 
they would talk often during the day. I never heard Frank 
end one of their conversations with anything other than, 
"Love you," or "I love you, too." You only had to be 
around them for a few minutes before you were not only 
in awe of their devotion to one another, but also a bit 
envious as well. 

Tony Schoenfelder 


Frank was quite amazing in a number of special ways. 
I remember his smile that encouraged all to sit and talk, 
his genuine respect for people's ideas and comments, 
and his creative imagination never at rest. He was 
dedicated to developing training programs and tools to 
enhance the effectiveness of project managers at NASA. 
Although his formal resources were limited in this 
endeavor, somehow he attracted talented individuals to 
join him. Textbooks define this as leadership. Frank was 
an extraordinary leader and a great friend. 

Dale Crossman 

I first met Frank over 20 years ago when I joined the 
Space Station Task Force. He liked to point out that he 
was the fourth person hired on the program, while I was 
somewhat later on the list. My response to him was that 
at least I was the second Irishman. I dubbed him "Father 
Mulcahy" after the priest in the television series M.A.S.H 
because so many people in the office brought their 
problems to him. 

After we both left Space Station, we went to 
different offices at NASA Headquarters, but stayed in 
frequent contact. After retiring from NASA, Frank put 
together a program to tap the talents of other retired 
NASA managers. The last time I saw him was at a 
meeting on December 3rd, and he was as upbeat as ever. 

As distinguished as his career was, Frank's real 
strength was his character. He was one of my best 
friends, and I miss him every day. 

John Sheahan • 
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letter from the editor-in-chief Dr Alexander Laufer 


Perfection Is in the Details — or Is It? 


After I earned my engineering doctorate at the University of Texas, 
I accepted a teaching position at Texas A&M University. By 1982 , 
/ was ready to return to the field and put principles to practice 


I MOVED BACK TO ISRAEL AND GOT A JOB MANAGING A 
large building project where I was in charge of both the 
design and construction. The complex I was working on 
was being built in Jerusalem — but the design took place 
in Tel Aviv. I spent my days shuttling back and forth 
between the two sites. 

It soon became clear that things weren't going 
according to the textbook. I had learned to prepare 
implementation plans as early as possible and as detailed 
as possible. 

My construction superintendent, an experienced 
engineer twenty years my senior, kept 
postponing the planning I asked him to do. 

He insisted we weren't ready to create a 
complete plan because details of the project 
kept changing. 

Eventually, I came to realize that he was 
right to delay the detailed planning, because 
quite often I would explain something I wanted done in 
the morning; then I would go to Tel Aviv in the 
afternoon and find out that the design had been altered 
and the information that I had passed along in the 
morning was no longer accurate. Still, I didn't know how 
to explain what I was observing-even to myself. 

I left that construction project to teach a summer 
graduate school class on construction productivity at 
Texas A&M. As pan of the course, I sent five teams of 
students to construction sites to see how productivity 
could be improved. The students set out armed with 
high-tech tools and prepared to conduct sophisticated 
measurement and analysis. I expected them to come 
back with recommendations to improve productivity at 
their sites by changes in project staffing, equipment use 
and the like. 

After weeks of study, they produced, instead, 
detailed short-term plans for the projects they had 
observed. As project managers, we were all taught to 


prepare comprehensive plans, with full details at the 
beginning of a project. But that wasn't what my students 
observed in the field, and it wasn't what I had experi- 
enced as a project manager. 1 began to question the 
accepted theory of project planning. Something so basic 
that it was alarming. 

Why, I wondered, didn't experienced project managers 
have these detailed plans in place before construction 
began? Why did they have to wait for mv students? 

After the course ended, I spent some time giving 
presentations at construction companies across the U.S. 

I shared my questions about planning with top 
managers at the best companies. No one threw 
me out of the room, and that was enough to 
keep me going. I continued to struggle to 
understand what I had observed. 

Then, a piece of writing came along to 
reinforce my thinking. In Jay R. Galbraith's 1977 
book, Organization Design, I found the missing piece of my 
puzzle: uncertainty as information gap. I came to under- 
stand that planning equals uncertainty reduction. In 
subsequent research, I was able to confirm this. I observed 
that uncertainty is not an exceptional state in an otherwise 
predictable process of project work. 

With this new insight, it was easy to see why my 
superintendent kept postponing his planning and why 
my graduate students didn't find detailed plans at the 
sites they visited: they needed to collect data onsite, after 
construction started. Detailed plans aren't possible in 
the absence of information. I learned that perfection is, 
indeed, in the details — but not prematurely. A project 
manager must adjust the degree of details in a project 
plan to the completeness of available information. 

It is so clear to me now, but it took me years to reach 
these conclusions. Before I could, I had to let go of 
assumptions that I had been taught. So much of learning, 
I have come to realize, begins with unlearning. • 


I began to 
question the 
accepted theory of 
project planning 
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